9章 設計の健全性をそこなうさまざまな悪魔たち

9.1 デッドコード

＝到達不能コード

VSCodeでPythonを書いていると気付きやすい印象（returnの後のコード）

発見次第すぐ削除

9.2 YAGNI原則

実際に必要になったときにのみ実装せよ (p.301)

You aren't going to need it＝必要ないでしょう

9.3 マジックナンバー

＝説明なき数値

定数として名前をつけるのでコメントも不要になる

値の変更にも強い

9.4 文字列型執着

1つの文字列としてカンマ区切り😱

意味の異なる値は、別の変数へ格納

9.5 グローバル変数

巨大データクラスもグローバル変数と同質

影響範囲が最小化するように設計しましょう。(p.308)

『オブジェクト指向でなぜつくるのか』でも同様の話があったと記憶している

9.6 null問題

例：防具を装備していない状態をnullで表現

至るところでnullチェックになる

（言語によっては?でつなぐ書き方。オプショナル・チェイニング）

何かを持っていない状態や未設定状態も、立派な状態 (p.312)

そもそもnullを取り扱わない設計にする（チェックを発生させない）

上の例では「装備なし」を表すインスタンス変数を導入

null安全を実現する機能の一つ：null非許容型

Kotlinの例

Stringはnull非許容

String?は許容

Pythonだとmypy？

NoneとのUnionでOptionalと表せるようになった（Python 3.10〜）

9.7 例外の握り潰し

例外をキャッチして何もしない

問題検出時にけたたましく叫ばせる

不正を許さないつながりで3章の完全コンストラクタ

Pythonのエラーの扱いについて

EuroPythonかUS PyConで見かけた記憶

9.8 設計秩序を破壊するメタプログラミング

リフレクションを使って値オブジェクトを不正な状態にする例

メタプログラミングは用途を限定する

9.9 技術駆動パッケージング

パッケージの区切り方、フォルダの分け方の話

構造的に似ているものどうしでフォルダ分け、パッケージ分けするのを技術駆動パッケージングと呼びます。(p.326)

例：設計パターンごとにファイル分類（ユースケースごと、エンティティごと）

Railsの例が出ているが、Djangoのappの中もmodels, viewsと技術駆動

ビジネス概念として強く関係し合うものどうしが一緒になるようフォルダ分け (p.327)

在庫というビジネス概念に関係するユースケースやエンティティを1箇所にまとめる

Pythonでモジュール分け、パッケージ分け、なにか指針はある？

9.10 サンプルコードのコピペ

サンプルコードからは離れる

言語仕様やライブラリの機能を説明するためのコード（用途が異なる）

＋あるべきクラス構造を設計する

IMO：それを知るのがこの本なのだと思う

9.11 銀の弾丸

ソフトウェア開発に銀の弾丸はない

大事なのは、どんな課題があるか、ある手法がその課題解決に効果的か、コスト的に問題にならないかを評価して判断する姿勢です。(p.330)